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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The present document specifies the technical realisation of the first phase of the network feature Support of Optimal 
Routeing (SOR) within the 3GPP system. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the technical reahsation of the first phase of the network feature Support of Optimal 
Routeing (SOR). The first phase of SOR provides: 

as a network operator option, a method to route a call from one mobile subscriber directly to another mobile 
subscriber who is in the same country as the calling mobile subscriber or in the called mobile subscriber's home 
country, without needing to connect the call via the HPLMN of the called subscriber, even though the called 
mobile subscriber has roamed outside his HPLMN; 

a method to forward calls when a called mobile subscriber who has roamed outside his home country is busy, or 
is not reachable, or does not reply, to a forwarded-to destination in the HPLMN country of the called subscriber 
or the VPLMN country of the called subscriber, without needing to connect the forwarded call via the VPLMN 
of the called subscriber; 

a method to combine the optimal routeing described in the first bullet point above with the optimal routeing 
described in the second bullet point above. 

OR of a call is permitted only if all entities involved in handling the call support OR. 

Other cases of optimal routeing (e.g. calls where the calling and called subscribers are in different countries, forwarding 
to a mobile subscriber or multiple forwarding) will be considered for inclusion in later phases. 
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• References are either specific (identified by date of publication, edition number, version number, etc.) or 
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Release as the present document. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

A subscriber: calling subscriber, who may be fixed or mobile 

B subscriber: mobile subscriber originally called by the A subscriber 

C subscriber: subscriber to whom the B subscriber has requested that calls be forwarded. The C subscriber may be 
fixed or mobile 

Direct route: call takes the direct route if the route from the serving PLMN of the A subscriber to the serving PLMN of 
the B subscriber is defined by the MSRN of the B subscriber rather than by the MSISDN of the B subscriber 

Early call forwarding: call forwarding from the IPLMN before the call has been extended to the VPLMN of the 
forwarding subscriber 

HPLMN leg: portion of the HPLMN route from the serving MSC of the A subscriber to an MSC in the HPLMN of the 
B subscriber 

HPLMN route: call takes the HPLMN route if the route from the serving MSC of the A subscriber to the serving MSC 
of the B subscriber is defined by the MSISDN of the called subscriber. This forces the call to be routed via the HPLMN 
of the B subscriber 

Interrogating PLMN (IPLMN): PLMN which interrogates the HPLMN of the B subscriber to obtain information to 
route the call to that subscriber or to the forwarded-to destination defined by the called mobile subscriber. The IPLMN 
is also the VPLMN of the A subscriber 

Late call forwarding: call forwarding after the call has been extended to the VPLMN of the forwarding subscriber. 
Late call forwarding may be invoked in the IPLMN or the VPLMN of the forwarding subscriber 

Reference address: address which defines the maximum charge which the A party is prepared to pay for the call leg 
which he originates 

Routeing address: address which the GMSC uses to route a call towards the B subscriber or the C subscriber 
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3.2 



Abbreviations 



Abbreviations used in the present document are listed in TS 21.905 [2]. 

For the purposes of the present document, the following abbreviations apply: 

BOIZC Barring of Outgoing InterZonal Calls 

BOIZC-exHC Barring of Outgoing InterZonal Calls except those directed to the HPLMN Country 

CMN CAMEL Modified Number 

FTN Forwarded-To Number 

FTNW Forwarded-To NetWork 

GMSCA The GMSC in the IPLMN, which may also be VMSCA 

GMSCB The GMSC in HPLMNB 

GMSCC The GMSC in HPLMNC 

HLRB The HLR of the B subscriber 

HLRC The HLR of the C subscriber 

HPLMNB The HPLMN of the B subscriber 

HPLMNC The HPLMN of the C subscriber 

lAM Initial Address Message 

IPLMN Interrogating PLMN 

ORLCF Optimal Routeing for Late Call Forwarding 

PRN Provide Roaming Number 

PSI Provide Subscriber Information 

RCH Resume Call Handling 

SIFIC Send Information For Incoming Call 

SIFOC Send Information For Outgoing Call 

SRI(B) Send Routeing Information (Basic call) 

SRI(F) Send Routeing Information (Forwarding information) 

VLRA The VLR of the A subscriber 

VLRB The VLR of the B subscriber 

VMSCA The VMSC of the A subscriber 

VMSCB The VMSC of the B subscriber 



4 Architecture 

4.1 Optimal routeing for basic mobile-to-mobile calls 

It is a network operator option whether to implement optimal routeing for basic mobile-to-mobile calls. 

The existing UMTS and GSM architectures support the primary technical requirement of optimal routeing for mobile- 
to-mobile calls (basic OR): that a GMSC can interrogate an HLR in a different PLMN to obtain routeing information 
for a mobile terminated call (see GSM 03.04 [1]). Three logically distinct PLMNs are involved in the handling of an 
optimally routed mobile-to-mobile call: 

the IPLMN, which is also the VPLMN of the calling mobile subscriber; 

- the HPLMN of the called mobile subscriber (HPLMNB); 

- the VPLMN of the called mobile subscriber (VPLMNB). 

Any two or all three of these PLMNs may be identical; in figure 1 they are shown as distinct. 

Figure 1 shows the communication between the IPLMN, HPLMNB and VPLMNB for an optimally routed 
mobile-to-mobile call. 



£75/ 



3GPP TS 23.079 version 5.5.0 Release 5 



ETSI TS 123 079 V5.5.0 (2004-06) 



VMSCA GMSCA 



gsmSSF 

A 



IPLMN 



lAM 
(ISUP) 



VMSCB 




VPLMNB 



Initial DP/ 
Connect 



\ Send Routeing 
\ Info/ack 



/Provide Roaming 
Number/ack 





HPLMNB 



Figure 1 : Architecture for optimal routeing of basic mobile-to-mobile call 

In figure 1 and throughout the present document, the term ISUP is used to denote the telephony signalling system used 
between exchanges. In this architecture the VMSC of the calling mobile subscriber (VMSCA) is integrated with the 
GMSC; communication between them is over an internal interface. A gsmSSF is also associated with VMSCA, to 
support CAMEL functionality; this is required for the support of optimal routeing of mobile-to-mobile calls. 

If the originating subscriber has a CAMEL subscription, then when VMSCA receives the setup message it sends an 
Initial DP message, containing the address digits received in the setup message, via the gsmSSF to the gsmSCF. If the 
gsmSCF determines that the destination defined by the address digits belongs to a GSM or UMTS PLMN, it responds to 
the Initial DP with a Connect or Continue With Argument message to VMSCA containing an indication that the call is 
eligible for optimal routeing. This causes VMSCA to route the call to the associated GMSC (GMSCA). 

If the GMSC is in the VPLMN of the calling mobile subscriber, is in a different PLMN from HLRB, it requests 
routeing information from HLRB using the MAP protocol. If HLRB determines that the call can be routed directly from 
the GMSC to VMSCB without contravening the charging requirements for optimal routeing given in subclause 9.1, it 
requests a roaming number from VERB using the MAP protocol, and VERB returns a roaming number in the Provide 
Roaming Number ack. HERB returns the roaming number to the GMSC in the Send Routeing Info ack. The GMSC 
uses the roaming number to construct an ISUP lAM, which it sends to VMSCB. The call is then handled according to 
the procedures defined in 3GPP TS 23.018 [6], except that if the call is answered GMSCA relays the answer event to 
VMSCA and includesthe destination address which it used to route the call, to allow VMSCA to generate the correct 
charging record. 

NOTE: If the GMSC relays an answer event to VMSCA before it has received an Answer message from the final 
destination (e.g. because of an interaction with a Specialised Resource Function) an incorrect destination 
address (or no destination address) can be sent to VMSCA, even though the call is eventually optimally 
routed. 
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4.2 Optimal routeing for conditional call forwarding 

Some cases of call forwarding on mobile subscriber not reachable (CFNRc) are handled in the IPLMN, without the call 
being extended to the VPLMN of the forwarding subscriber. For these cases, referred to in the present document as 
early call forwarding, the forwarding is already optimally routed. 

When a call has been extended from the GMSC to VMSCB, the procedures defined in 3GPP TS 23.018 [6] lead to any 
conditional call forwarding being routed from VMSCB to the forwarded-to destination; this is referred to in this 
specification as late call forwarding. Optimal routeing for late call forwarding (ORLCF) allows VMSCB to return 
control of the call to the GMSC, which can then route the call to the forwarded-to destination. 

Figure 2 shows the architecture for ORLCF. Phase 1 of SOR does not include optimal routeing of forwarding to a 
mobile subscriber, so optimal routeing of the forwarding leg is not considered. 
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Figure 2: Architecture for optimal routeing of late call forwarding 

After the call has been extended from the GMSC to VMSCB, if the VMSC/VLR determines that the call should be 
forwarded it requests the GMSC to resume call handling. The GMSC uses the forwarding information received in the 
request to resume call handling, or interrogates HLRB for forwarding information, depending on the indication received 
from the HLR with the roaming number. If the GMSC determines that the call can be routed directly to the forwarded- 
to destination without contravening the charging requirements for optimal routeing given in subclause 9.1 it 
acknowledges the request, clears the traffic connection to VMSCB and sends an ISUP lAM to the forwarded-to local 
exchange. 
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5 Optimal routeing for basic mobile-to-mobile calls: 

message flows 

It is a network operator option whether to implement optimal routeing for basic mobile-to-mobile calls. 

This clause does not consider the handling of calls to a fixed network B subscriber. 

The description in this clause of the handling of optimal routeing for basic mobile-to-mobile calls is informative, not 
normative. Further, the description does not consider the effects of other services or features, except where these are 
specifically mentioned. 

The message flow for an optimally routed call from one mobile subscriber to another mobile subscriber is shown in 
figure 3. For simplicity of description, it is assumed that forwarding of calls from the B subscriber is not required. Solid 
lines indicate circuit-associated signalling; dashed lines indicate connectionless signalling. 
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Figure 3: Message flow for optimal routeing of basic mobile-to-mobile call 



Successful outcome 



When VMSCA receives a Setup message from the MS, it sends a request for information to handle the outgoing call to 
VLRA, according to the procedures described in 3GPP TS 23.018 [6]. If VLRA determines that the MS is allowed 
service, it returns a positive acknowledgement, including an indication that the subscriber has a CAMEL subscription, 
so that VMSCA will request instructions via the gsmSSF (not shown in this diagram) from the gsmSCF. 

If the gsmSCF recognises the B subscriber address as belonging to a UMTS or GSM PLMN (decision ORl:Y), it sends 
a Connect message or a Continue With Argument message, containing an indication that the call is eligible for optimal 
routeing, to VMSCA. This causes VMSCA to route the call to the associated GMSC function (GMSCA). GMSCA 
checks the identity of HPLMNB. If GMSCA is in a different PLMN from HLRB, it then sends a request for routeing 
information (SRI(B)) to HLRB; this request contains an indication that it is an optimal routeing enquiry for information 
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to route a basic call. If HLRB is prepared to accept an optimal routeing enquiry from GMSCA (decision OR2: Y), it 
checks whether at least one of the three conditions: 

- the GMSC is in the same country as VMSCB; 
the HLR is in the same country as VMSCB; 

- the GMSC is in the same PLMN as the HLR; 

is met. If it is (decision OR3:Y), HLRB sends a request for a roaming number (PRN) to VLRB; the request contains an 
indication that it is for an optimally routed call. If VLRB supports optimal routeing (decision OR4:Y), it returns the 
roaming number in the PRN ack, and HLRB relays the roaming number in the SRI ack to GMSCA. GMSCA constructs 
an ISUP lAM using the roaming number, and sends it to VMSCB, which processes the incoming lAM according to the 
procedures described in 3GPP TS 23.018 [6]. 

5.2 Unsuccessful outcome 

Error situations which lead to failure of the call, rather than non-optimal routeing, are not described in this subclause. 

5.2.1 B subscriber address not recognised as belonging to a UMTS or 
GSM PLMN 

If the gsmSCF does not recognise the B subscriber address as belonging to a UMTS or GSM PLMN (decision ORl:N), 
it sends a Connect or Continue With Argument message, omitting the indication that the call is eligible for optimal 
routeing. VMSCA constructs an lAM using the B subscriber address and sends it to GMSCB in HPLMNB. GMSCB 
analyses the address received in the lAM, and sends a request for routeing information (SRI(B)) to HLRB; this request 
contains an indication that it is not an optimal routeing enquiry. Because GMSCB is in the same PLMN as HLRB, it 
will always be able to derive an HLR address. HLRB sends a request for a roaming number (PRN) to VLRB. VLRB 
returns the roaming number in the PRN ack, and HLRB relays the roaming number in the SRI ack to GMSCB. GMSCB 
constructs an ISUP lAM using the roaming number, and sends it to VMSCB, which processes the incoming lAM 
according to the procedures described in 3GPP TS 23.018 [6]. 

5.2.2 HLRB or VLRB does not support optimal routeing 

If HLRB is not prepared to accept an optimal routeing enquiry from GMSCA , because: 
it does not support optimal routeing for basic mobile-to-mobile calls, or 

- because there is no agreement for optimal routeing for basic mobile-to-mobile calls between the operators of 
GMSCA and HLRB, or 

- because optimal routeing of basic mobile-to-mobile calls to the specific B subscriber is not allowed, 

(decision OR2:N), it returns an SRI negative response (shown in figure 3 as 'SRI error'). This causes GMSCA to 
construct an lAM using the B subscriber address and send it to GMSCB, as described in subclause 5.2.1. 

If VLRB does not support optimal routeing (decision OR4:N), it returns a PRN negative response (shown in figure 3 as 
'PRN error'). This causes HLRB to return an SRI negative response (shown in figure 3 as 'SRI error'), which in turn 
causes GMSCA to construct an lAM using the B subscriber address and send it to GMSCB, as described in 
subclause 5.2.1. 

5.2.3 OR charging requirements contravened 

If HLRB determines that the call cannot be routed directly from GMSCA to VMSCB without contravening the charging 
requirements for optimal routeing given in subclause 9.1 (decision OR3:N) it sends a request for subscriber information 
(PSI) to VLRB. VLRB sends a response indicating whether the B subscriber is detached or in some other state. If the B 
subscriber is not detached, HLRB sends an SRI negative response (shown in figure 3 as 'SRI error') to GMSCA, which 
constructs an lAM using the B subscriber address and sends it to GMSCB, as described in subclause 5.2.1. 
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6 Optimal routeing for conditional call forwarding: 

message flows 

The description in this clause of the handhng of optimal routeing for conditional call forwarding is informative, not 
normative. Further, the description does not consider the effects of other services or features, except where these are 
specifically mentioned. 

Two cases of conditional call forwarding are described in this clause: 

early call forwarding to a fixed destination; 

late call forwarding to a fixed destination. 

For phase 1 of SOR, no attempt is made to route a call directly from the GMSC to a forwarded-to mobile subscriber; if 
the forwarded-to subscriber is mobile, the call is routed from the GMSC to a GMSC in the HPLMN of the forwarded-to 
subscriber. 



6.1 Early call forwarding 



Early call forwarding is defined as call forwarding from the IPLMN before the call has been extended to the VPLMN 
of the forwarding subscriber. CFU and CFNRc when the forwarding mobile subscriber is IMSI detached are examples 
of early call forwarding. Early call forwarding is effectively optimally routed, because the call takes the most direct 
route possible from the IPLMN to the forwarded-to destination. 

The message flows for early call forwarding to a fixed destination are shown in figure 4a (forwarding without VLR 
interrogation) and figure 4b (forwarding after VLR interrogation). The IPLMN is shown as distinct from HPLMNB, on 
the assumption that the original call towards the B subscriber was optimally routed; however if optimal routeing of 
basic mobile-to-mobile calls is not implemented, the IPLMN will be the same as HPLMNB. Solid lines indicate circuit- 
associated signalling; dashed lines indicate connectionless signalling. 

6.1 .1 Forwarding without interrogation of VLRB 
6.1 .1 .1 Successful outcome 

GMSCA sends a request for routeing information (SRI(B)) to HLRB. If HLRB determines that the call is to be 
forwarded without needing to signal to VLRB then HLRB returns the forwarded-to number (FTN) in the SRI ack. 

If GMSCA determines that the call can be forwarded to LEC without contravening the charging requirements for 
Support of Optimal Routeing given in subclause 9.1 (decision OR:Y) it constructs an ISUP lAM using the FTN and 
sends it to LEC. 
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Figure 4a: Message flow for early call forwarding to a fixed destination - forwarding without 

interrogation of VLRB 

6.1 .1 .2 Unsuccessful outcome 

Error situations which lead to failure of the call, rather than non-optimal routeing, are not described in this subclause. 

If GMSCA determines that the call cannot be forwarded to LEC without contravening the charging requirements for 
Support of Optimal Routeing given in subclause 9.1 (decision OR:N) it constructs an lAM using the B subscriber 
address and sends it to GMSCB. 

GMSCB sends a request for routeing information (SRI(B)) to HLRB. If HLRB determines that the call is to be 
forwarded, as described in subclause 6.1.1.1, it returns the FTN in the SRI ack. 

GMSCB constructs an lAM using the FTN and sends it to LEC. 

6.1 .2 Forwarding after interrogation of VLRB 



6.1.2.1 



Successful outcome 



GMSCA sends a request for routeing information (SRI(B)) to HLRB. HLRB sends a request for the subscriber status 
(PSI) to VLRB. If the record in VLRB for the B subscriber shows that the B subscriber is IMSI detached, VLRB 
indicates this in the PSI ack. Alternatively, if HLRB determines that at least one of the three conditions: 

- the GMSC is in the same country as VMSCB; 
the HLR is in the same country as VMSCB; 

- the GMSC is in the same PLMN as the HL; 

is met, it sends a request for a roaming number (PRN) to VLRB. If the record in VLRB for the B subscriber shows that 
the B subscriber is IMSI detached, VLRB indicates this in a PRN negative response. If HLRB determines that CFNRc 
should be invoked, it returns the forwarded-to number (FTN) in the SRI ack. 
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If GMSCA determines that the call can be forwarded to LEC without contravening the charging requirements for 
Support of Optimal Routeing given in subclause 9.1 (decision OR:Y) it constructs an ISUP lAM using the FTN and 
sends it to LEC. 
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NOTE: HLRB may send a PRN to VLRB, and receive a PRN negative response indicating absent subscriber, to 
determine that CFNRc sliould be invol<ed. 

Figure 4b: Message flow for early call forwarding to a fixed destination - forwarding after 

interrogation of VLRB 



6.1.2.2 



Unsuccessful outcome 



Error situations which lead to failure of the call, rather than non-optimal routeing, are not described in this subclause. 

If GMSCA determines that the call cannot be forwarded to LEC without contravening the charging requirements for 
Support of Optimal Routeing given in subclause 9.1 (decision OR:N), it constructs an ISUP lAM using the B subscriber 
address and sends it to GMSCB. 

GMSCB sends a request for routeing information (SRI(B)) to HLRB. HLRB sends a request for a roaming number 
(PRN) to VLRB. If the record in VLRB for the B subscriber shows that the B subscriber is IMSI detached, VLRB 
indicates this in the PRN ack. If HLRB determines that CFNRc should be invoked, it returns the forwarded-to number 
(FTN) in the SRI ack. 

GMSCB constructs an lAM using the FTN and sends it to LEC. 
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6.2 Late call forwarding 



Late call forwarding is defined as call forwarding after the call has been extended to the VPLMN of the forwarding 
subscriber. CFB, CFNRc on no response to paging and CFNRy are examples of late call forwarding. In the absence of 
OR, late call forwarding occurs in the VPLMN of the forwarding party; if OR applies, late call forwarding occurs in the 
IPLMN. 

The message flow for optimal routeing of late call forwarding to a fixed destination is shown in figure 5. The IPLMN 
may be distinct from HPLMNB or the same as HPLMNB, depending on whether or not the original call to VPLMNB 
was optimally routed, but this description assumes that the original call to VPLMNB was optimally routed. For 
simplicity of description, the separation of VMSCA and GMSCA (described in clause 5 & subclause 6.1) is omitted. 
Solid lines indicate circuit-associated signalling; dashed lines indicate connectionless signalling. 
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Figure 5: Message flow for optimal routeing of late call forwarding to a fixed destination 
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6.2.1 Successful outcome 

The GMSC obtains a roaming number from HLRB to route the call to VMSCB, as described in subclause 5.1. The SRI 
ack also includes an indication of whether the GMSC should interrogate the HLR for routeing information for late call 
forwarding. The GMSC constructs an lAM using the roaming number, and sends it to VMSCB. When VMSCB 
receives the JAM, it requests subscriber information for the incoming call (SIFIC) from VLRB. If VLRB determines 
that the call should be forwarded, because the called mobile subscriber is busy, or is not reachable, or has not replied to 
the call before the no-reply call timer has expired, it returns a SIFIC ack containing the forwarded-to number, the 
forwarding reason, the GMSC address and the call reference number to VMSCB. VMSCB sends a request to resume 
call handling (RCH) to the GMSC; the RCH includes the forwarded-to number, the forwarding reason and the basic 
service information received in the SIFIC ack. 

If the HLR indicated in the SRI ack which contained the MSRN that the GMSC should interrogate the HLR for 
forwarding information (FIR:Y), the GMSC then sends a request for forwarding information (SRI(F)), containing the 
forwarding reason and the basic service group which applies for this call, to HLRB. HLRB responds with the 
appropriate forwarded-to number. 

If the HLR indicated in the SRI ack which contained the MSRN that the GMSC should not interrogate the HLR for 
forwarding information (FIR:N), the GMSC checks the forwarded-to number received in the RCH. 

If the GMSC determines that the call can be forwarded to the forwarded-to destination without contravening the 
charging requirements for Support of Optimal Routeing given in subclause 9.1 (decision OR:Y) it: 

sends an RCH ack to VMSCB to indicate that control of the call has been accepted; 

sends an ISUP Release message indicating normal clearing to VMSCB to release the traffic circuit; 

constructs an lAM using the forwarded-to number, and sends it to LEC. 

6.2.2 Unsuccessful outcome 

Error situations which lead to failure of the call, rather than non-optimal routeing, are not described in this subclause. 

6.2.2.1 GMSC does not support OR 

If the GMSC does not support OR, it omits the 'or-capability' information element from the SRI(B) request. The HLR 
then sends the 'OR not supported in GMSC indicator in the PRN to VLRB. VMSCB will not send the RCH to the 
GMSC if the 'OR not supported in GMSC indicator was received in the PRN. Instead, the call will be forwarded at 
VMSCB. 

6.2.2.2 HLRB does not support OR 

If HLRB does not support OR, it does not relay the GMSC address and the call reference number which it received in 
the SRI(B), so VMSCB cannot send the RCH to the GMSC. Instead, the call will be forwarded at VMSCB. 

6.2.2.3 VMSCB/VLRB does not support OR 

If VMSCBA^LRB does not support OR, VMSCB cannot send the RCH to the GMSC. Instead, the call will be 
forwarded at VMSCB. 

6.2.2.4 OR charging requirements contravened 

If the original call to VMSCB was optimally routed, the GMSC can route the call to the forwarded-to destination only if 
the charge to do so is no more than the charge to route the call to HPLMNB. If this requirement, determined as 
described in subclause 9.1, is not met (decision OR:N) the GMSC returns an RCH negative response (shown in figure 5 
as 'RCH error') to VMSCB, which then forwards the call. 



£75/ 



3GPP TS 23.079 version 5.5.0 Release 5 1 9 ETSI TS 1 23 079 V5.5.0 (2004-06) 

If the original call to VMSCB was not optimally routed, the GMSC can route the call directly to the forwarded-to 
destination only if the charge to do so is no more than the charge for the routeing to VMSCB. If this requirement, 
determined as described in subclause 9.1, is not met (decision OR:N) the GMSC returns an RCH negative response 
(shown in figure 5 as 'RCH error') to VMSCB, which then forwards the call. 



7 Interactions between optimal routeing and 

supplementary services 



7.1 Call forwarding 



If an optimally routed call encounters early call forwarding, GMSCA attempts to route the call to the forwarded-to 
destination. The forwarded-to destination is the C subscriber if the C subscriber is not a mobile subscriber, or the 
HPLMN of the C subscriber if the C subscriber is a mobile subscriber. If GMSCA cannot route the call to the 
forwarded-to destination without contravening the charging requirements for Support of Optimal Routeing given in 
subclause 9.1, the call is routed to a GMSC in the HPLMN of the B subscriber. 

If an optimally routed call encounters late call forwarding, GMSCA attempts to route the call to the forwarded-to 
destination. The forwarded-to destination is the C subscriber if the C subscriber is not a mobile subscriber, or the 
HPLMN of the C subscriber if the C subscriber is a mobile subscriber. If GMSCA cannot route the call to the 
forwarded-to destination without contravening the charging requirements for Support of Optimal Routeing given in 
subclause 9.1, the call is routed from VMSCB to the forwarded-to destination. 

The handling of call forwarding at HLRB for optimally routed calls is encapsulated in the procedures 
First_Forwarding_HLR, PRN_Error_HLR, Handle_CFB, Handle_CFNRc and Handle_CFNRY, which are specified in 
3GPPTS 23.018 [6]. 



7.2 Closed User Group (CUG) 



The handling of CUG checking for outgoing calls at VLRA is encapsulated in the process OCH_VLR, which is 
specified in 3GPP TS 23.018 [6]. 

The handling of CUG checking at HLRB is encapsulated in the procedures Subscription_Check_HLR and 
Forward_CUG_Check, which are specified in 3GPP TS 23.018 [6]. 



7.3 Advice of Charge 



Advice of Charge (Information) and Advice of Charge (Charging) do not take account of whether a call has been 
optimally routed. 



7.4 Call barring 



It has been accepted in principle that all supplementary service call barring programmes except for BAIC are applied 
for cost control reasons, and that therefore barring should be applied on the basis of the cost of the actual route taken by 
the call. For phase 1 of Support of Optimal Routeing, this principle does not apply. Barring of outgoing calls is applied 
on the basis of the B subscriber number. Barring of all incoming calls will prevent a call to the served mobile 
subscriber, whether or not the call is optimally routed. If Barring of Incoming Calls when roaming outside the home 
PLMN country is active and operative it will prevent a call to the B subscriber even if the A subscriber pays to route the 
call to the VMSC of the B subscriber. 

The handling of barring of outgoing calls at VLRA is encapsulated in the process OCH_VLR, which is specified in 
3GPPTS 23.018 [6]. 

The handling of barring of incoming calls at HLRB is encapsulated in the procedure Subscription_Check_HLR, which 
is specified in 3GPP TS 23.018 [6]. 
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The interactions between barring of outgoing calls and call forwarding for phase 1 of Support of Optimal Routeing are 
defined in 3GPP TS 22.082 [4]. 

The interactions between BIC-Roam and call forwarding for phase 1 of Support of Optimal Routeing are defined in 

3GPPTS 22.082 [4]. 

7.5 Other supplementary services 

The effects of the following supplementary services on optimally routed calls are identical to their effects on non- 
optimally routed calls, so they are omitted from the present document: 

- CLIP, CUR, COLP, COLR (3GPP TS 23.081); 

- CW, HOLD (3GPP TS 23.083); 

- MPTY (3GPP TS 23.084); 

- ECT(3GPPTS 23.091). 



8 Interactions between optimal routeing and other 

network features 



8.1 Operator determined barring 



The principles for the interactions between operator determined barring and optimal routeing are the same as those for 
interactions between supplementary service barring and optimal routeing. 

8.2 CAMEL 

The principles for interactions between CAMEL services and optimal routeing are specified in this subclause. The 
interworking between CAMEL processing and optimal routeing in the GMSC and the terminating VMSC is specified in 
subclause 9.4 and 3GPP TS 23.018 [6]. 

If a mobile-originating CAMEL service modifies the number entered by the A subscriber, VMSCA treats the number 
returned by the gsmSCF in the same way as a number received in the SETUP message, i.e.: 



If the gsmSCF indicated that the call is eligible for optimal routeing, VMSCA sends a signal containing the 
modified number to the associated GMSC, which sends a request for routeing information to the appropriate 
HLR; 

If the gsmSCF did not indicate that the call is eligible for optimal routeing, VMSCA sends an lAM containing 
the modified number to a GMSC in HPLMNB, which sends a request for routeing information to the appropriate 
HLR. 

If a mobile-terminating CAMEL service modifies the number received by the GMSC, the GMSC treats the number 
returned by the CAMEL server in the same way as a forwarded-to number, i.e. it checks it against the optimal routeing 
criteria in subclause 9. 1 but does not analyse it to find if it can derive an HLR address. If the number returned by the 
CAMEL server does not satisfy the optimal routeing criteria in subclause 9.1 and the GMSC is not in the same PLMN 
as HLRB, the GMSC will route the call to a GMSC in the same PLMN as HLRB. This will lead to a repetition of the 
mobile terminating CAMEL interaction. 

If the call is to be forwarded early at the GMSC (whether by a UMTS-standardised call forwarding service or by a 
CAMEL-based call forwarding service) and a mobile originating CAMEL service applies to the forwarding subscriber, 
the GMSC checks the number which results from the CAMEL service against the optimal routeing criteria in subclause 
9. 1 . If the number returned by the CAMEL server does not satisfy the optimal routeing criteria in subclause 9.1, the 
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GMSC will not route the call to the forwarded-to destination. The GMSC will route the call to a GMSC in the same 
PLMN as HLRB. This will lead to a repetition of the mobile originating CAMEL interaction. 

If the call is optimally routed back to the GMSC (optimal routeing of late call forwarding) and a mobile originating 
CAMEL service applies to the forwarding subscriber, then the GMSC does not check the number which results from the 
CAMEL service against the optimal routeing criteria in subclause 9.L 

NOTE: Service Logic designers should be aware that Optimal Routeing of Late Call Forwarding (ORLCF) may 
be combined with Optimal Routeing of basic mobile to mobile calls (Basic Optimal Routeing - BOR) in a 
single call. The ORLCF handling in the GMSC may be subject to Mobile Terminating (MT) CAMEL 
handling and Mobile Forwarding (MF) CAMEL handling, as depicted in Procedure OR_Handle_RCH. 
Both the MT CAMEL Service and the MF CAMEL Service may provide a new destination for the 
forwarded leg. 

When BOR and ORLCF are combined within one call, and the MT CAMEL Service or the MF CAMEL 
Service provides a new destination for the forwarded leg, then these CAMEL Services should take 
particular care, if they need to ascertain whether this new destination complies with the optimal routeing 
criteria as specified in subclause 9. 1 . 



9 Functional requirements of entities performing 

optimal routeing 

9.1 Charging requirements for optimal routeing 

MoU have imposed two constraints for the charging of optimally routed calls: 

No subscriber shall pay more for a call which has been optimally routed than he would do under the present 
routeing scheme described in GSM 03.04 [1] in the subclauses describing the call cases where the GMSC is in 
the same PLMN as the HLR. 

At least for the first phase of Support of Optimal Routeing, the charge for one leg of a call shall be paid for 
entirely by one subscriber. 

These constraints mean that the direct route for a call cannot always be used. For example, if the calling mobile 
subscriber (the A subscriber) is in Germany, and the B subscriber's HPLMN is in Switzerland but he has roamed to 
Finland, the charge payable by the A subscriber to route the call by the direct route to Finland would be greater than the 
charge payable to route the call to HPLMNB, so the HPLMN route must be used. 

In the first phase of Support of Optimal Routeing, it cannot be assumed that a GMSC is able to calculate the charge 
payable for the direct route and the charge payable for the HPLMN leg. The MoU requirements can be met by applying 
more stringent (but simpler) criteria for deciding whether the direct route may be used: 

If the country code of the destination exchange and the country code of the GMSC are the same, then the direct 
route may be used. 

Otherwise, for a call leg which is chargeable to the A subscriber, if the country code of the destination exchange 
and the country code of HPLMNB are the same, then the direct route may be used. 

Otherwise, the HPLMN route shall be used. 

In certain cases, the second criterion above (equality of country codes for the HPLMN and the destination exchange) 
may not be enough to determine equality of the charges payable for the direct route and the HPLMN route. In these 
cases, analysis of the national destination code as well as the country code is required; however the principle is still that 
if the two numbers are the same to the depth of analysis required then the direct route may be used. 

For optimal routeing of late call forwarding, the constraints are satisfied if the following criteria are applied: 

if the country code of the forwarded-to exchange and the country code of the GMSC are the same, then the 
forwarded call may be routed directly from the GMSC to the forwarded-to exchange; 
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otherwise, if the country code of the forwarded-to exchange and the country code of HPLMNB are the same, 
then the forwarded call may be routed directly from the GMSC to the forwarded-to exchange; 

otherwise, if the country code of the forwarded-to exchange and the country code of VPLMNB are the same, 
then the forwarded call may be routed directly from the GMSC to the forwarded-to exchange; 

otherwise the forwarded call shall be routed through VPLMNB. 

9.2 Functional behaviour of VIVISCA 

The functional behaviour of VMSCA is specified in 3GPP TS 23.018 [6]. The only functions specific to optimal 
routeing are: 

Routeing the call to the associated GMSC function if the gsmSCF indicates that the call is eligible for optimal 
routeing; 

The transfer of the destination address, if it is received in the indication of the answer event, to the call data 
record, to allow the correct charge for the call to be made. This function is required only if VMSCA supports 
optimal routeing of mobile-to-mobile calls. 

9.3 Functional behaviour of VLRA 

The functional behaviour of VLRA is specified in 3GPP TS 23.018 [6]. 

9.4 Functional behaviour of GMSC 

When a call is being forwarded the forwarding leg is controlled by a process MT_CF_MSC which runs in the 
forwarding MSC (VMSC or GMSC). If CAMEL processing of the forwarding leg indicates that Basic Optimal 
Routeing of the forwarding leg should be attempted, the forwarding MSC may use the services of an associated GMSC 
for the forwarding leg, i.e. the associated GMSC requests routeing information from HLRC. In this case, the forwarding 
leg is processed in the same way as a mobile-originated call from mobile subscriber B. 

The functional behaviour of a GMSC is specified in 3GPP TS 23.018 [6]. The procedures specific to Support of 
Optimal Routeing are specified in this subclause. 

9.4.1 Procedure OR_Set_ORA_Parameters 

9.4.2 Procedure OR_Handle_RCH 

Sheet 1: if the GMSC receives O-CSI or D-CSI in Resume Call HandHng, then the GMSC shall verify whether it 
supports the CAMEL Phases indicated in O-CSI and D-CSI. If either or both of O-CSI and D-CSI indicates CAMEL 
Phase 4, then the GMSC shall also verify whether the Offered CAMEL4 CSIs of the GMSC includes support for O-CSI 
and D-CSI. If the required CAMEL Phases or the required CAMEL4 CSIs are not supported in the GMSC, then the 
GMSC disallows the Optimal Routeing request. Refer to 3GPP TS 23.078 [7] for a description of the Offered CAMEL4 
CSIs. 

Sheet 1 : if the GMSC interrogates the HLR for a Forwarded-to number, the Routeing address is the Forwarded-to 
number received in the Send Routeing Info ack; otherwise the Routeing address is the Forwarded-to number received in 
the Resume Call Handling. 

Sheet 1: the task "Destination address := FTN" is executed only if the GMSC supports optimal routeing of basic mobile- 
to-mobile calls. 

Sheet 1 : the procedure Route_permitted is called to verify the number received in Resume Call Handling or the number 
received from HLR. If the result is 'False', then the GMSC disallows the Optimal Routeing. The call forwarding will 
now be done by the VMSC. 

Note When the procedure Route_permitted returns result 'False', then the gsmSCF is not informed about the 

forwarding and can therefore not provide an alternative destination address. Reason is that once the 
gsmSCF is informed about forwarding, the call forwarding can not be returned to the VMSC. 
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Sheet 2: the procedure CAMEL_MT_GMSC_Notify_CF is specific to CAMEL phase 2 or higher; it is specified in 
3GPP TS 23.078 [7]. If the GMSC does not support CAMEL phase 2 or higher, processing continues from the 
"Continue" exit of the test "Resuh". 

If the result of the procedure CAMEL_MT_GMSC_Notify_CF is 'Fail' or 'Release', then the call will be released. 

If the result of the procedure CAMEL_MT_GMSC_Notify_CF is 'Reconnect', then the GMSC allows the Optimal 
Routeing. The GMSC will then start a call forwarding process. 

Sheet 2: when the procedure Route_permitted on sheet 1 returns result 'False', then the GMSC returns 'OR not allowed' 
to the VMSC. The call forwarding will now be done by the VMSC. 

Sheet 3: the procedure Activate_CF_Process is specified in 3GPP TS 23.018 [6]. When procedure Activate_CF_Process 
returns result 'Release' or 'Fail', the call is released. 

If the result is 'Pass', then the GMSC allows the Optimal Routeing. 

Sheet 3: the procedure UUS_GMSC_Check_Forwarding is specific to UUS; it is specified in 3GPP TS 23.087 [9]. 

Sheet 3: the procedure CAMEL_Store_Destination_Address is specific to CAMEL phase 3 or higher; it is specified in 
3GPPTS 23.078 [7]. 

Sheet 3: the called party address sent in the lAM to the process MT_CF_MSC is the Forwarded-to number received in 
the Perform Call Forwarding ack. 

Sheet 3: the process MT_CF_MSC is specified in 3GPP TS 23.018 [6]. 

9.4.3 Procedure Route_Permitted 

9.4.4 Procedure OR_Handle_SRI_Negative_Response 

'Non-fatal' error situations, which cause the call to be routed through a GMSC in the same PLMN as the HLR, are: 
Send Routeing Info request rejected because the HLR does not support OR. 
Protocol error. 
System failure. 

- Unexpected data value. 
Data missing. 

OR not allowed. 
'Fatal' negative responses, which cause the GMSC to return a 'fail' result, are: 
Unknown subscriber. 
Number changed. 
Bearer service not provisioned. 
Teleservice not provisioned. 

- Call barred. 

- CUG reject. 
Forwarding violation. 
Facility not supported. 
Absent subscriber. 
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Figure 6: Procedure OR_Set_ORA_Parameters 
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Procedure OR Handle RCH 
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Figure 7a: Procedure OR_Handle_RCH (sheet 1) 
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Procedure OR Handle RCH 



H_RCH2(3) 



: Procedure in the GMSC to ; '-. 

■ handles Resume Call Handling '■"': 
: request : 



o 



signals to/lrom the left are N 

to/from the originating exchange; ^ 
signals to/from the right are 
to/from the destination exchange 
unless indicated otherwise 



See TS 23.078 



Resume 
Call Handling 




response: 
Forwarding 



> 



Set negative 
response: 
Forwarding 

Mssi 




Resume Call 
Handling 
negative response 



> 



Resume 
Call Handling 
negative response 



> 



o 



Set negative 
response: 



Resume 
Call Handling 
negative response 



Figure 7b: Procedure OR_Handle_RCH (sheet 2) 
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Procedure OR Handle RCH 



H_RCH3(3) 



Procedure in the GMSC to :\ 
handle a Resume Call Handling 
request : 



Signals to/from the left are 
to/rrom the originating exchal 
signals to/from the right are 
to/from the destination exchan( 
unless indicated otherwise 




Figure 7c: Procedure OR_Handle_RCH (shieet 3) 
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Procedure Route Permitted 



RP1(1) 



Procedure to check 
whether routeing is perrni^ed 
to the specified address 



Procedure Route_Permitted\ 
FPAR iN OR, Requested address, 
Reference Address 
IN/OUT Route permitted 




Figure 8: Procedure Route_Permitted 
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Procedure OR_Handle_SRI_Negative_Response 



' Procedure in the GMSC to|\ 
I handle a Send Routeing IrJfo^ 
negative response for 
I optimal routeing 





Destination 
address:= 
Reference 
address 



Result:= 

Pass 



H_SRINR1(1) 



Figure 9: Procedure OR_Handle_SRI_Negative_Response 



9.5 Functional behaviour of HLR 

The functional behaviour of an HLR is specified in 3GPP TS 23.018 [6]. The procedures specific to Support of Optimal 
Routeing are specified in this subclause. 
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9.5.1 Procedure OR_HLR_CF 

Sheet 1: if the HLR does not support optimal routeing of basic mobile-to -mobile calls, the test "Optimal routeing 
allowed" takes the "No" exit. 

Sheet 2: the procedures Handle_CFB, Handle_CFNRc and Handle_CFNRy are specified in 3GPP TS 23.018 [6]. 

9.5.2 Procedure OR_HLR_lnterrogate_VLR 

If the HLR does not support optimal routeing of basic mobile-to-mobile calls, this procedure will be executed only if 
the Send Routeing Info was from a GMSC in the same PLMN as the HLR, i.e. this was not an Optimal Routeing 
enquiry. 

The procedure Handle_CFNRc is specified in 3GPP TS 23.018 [6]. 
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Procedure OR HLR CF 



0RHLRCF1(2) 



I Procedure in the HLR , \ 
1 1) handle cptimally routed 
I call forwardng i 



Fonwarding 

interrogation 

sufported? 




Figure 10a: Procedure OR_HLR_CF (sheet 1) 
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Procedure OR HLR CF 



Procedure in the HLR , \ 
, to handle optimally routed 
I call forwarding i 




Handle_CFNRy 



i See TS 23.018 




Set negative 
response: 

Forwarding 
violation 




See TS 23.018 




ORHLRCF2(2) 





Set negative 

response: 
No subscriber 
reply 





Forwarding reason= 
not reachable? 



Handle CFNRc 





Set negative 
response: 

Absent 
Subscriber 




Fonwarding reason= 
busy? 



i See TS 23.01 8 





Set negative 

response: 

Forwarding 

violation 




Result:= 
Forward 




Set negative 

response: 

Busy subscriber 





Figure 10b: Procedure OR_HLR_CF (sheet 2) 
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Procedure OR_HLRJnterrogate_VLR 



HLRINTV1(1) 



Procedure in the HLR x 
, to handle onterrogation of 
I the VLR for optimal routeing 



Signals to/from the right] 
are to/from the VLR 



Set parameter 

for PRN: OR 

not supported 

inGMSC 





Result:= 
Continue 





Provide 
Subscriber 
Info negative 
response 



- nSeeTS 23.018 



Set negative 
response: 

Forwarding 
violation 



Set negative 

response: 

OR not 

allowed 



Result:= 
Fail 




Figure 11: Procedure OR_HLR_lnterrogate_VLR 
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9.6 Functional behaviour of VLRB 

9.6.1 Functional behaviour of VLRB for provision of subscriber information 

The functional behaviour of VLRB for provision of subscriber information is specified in 3GPP TS 23.018 [6]. 

9.6.2 Functional behaviour of VLRB for roaming number allocation 

The functional behaviour of VLRB for roaming number allocation is specified in 3GPP TS 23.018 [6]. The only 
function specific to Support of Optimal Routeing is the storage of the OR indicator, the 'OR not supported in GMSC 
indicator, the GMSC address and the call reference number if VLRB receives them in the Provide Roaming Number 
request. 

9.6.3 Functional behaviour of VLRB when handling an incoming call 

The functional behaviour of VLRB when handling a request for information to handle an incoming call is specified in 
3GPP TS 23.018 [6]. The only functions specific to Support of Optimal Routeing are: 

the inclusion in the Complete Call or Process Call Waiting, if the call is to be offered to the B subscriber, of the 
OR indicator and the GMSC address if VLRB received them in the Provide Roaming Number request; 

the inclusion in the Send Info For Incoming Call response, if the call is to be forwarded, of: 

the OR indicator, the 'OR not supported in GMSC indicator, the GMSC address and the call reference 
number if VLRB received them in the Provide Roaming Number request; 

the basic service which applies for this call. 

9.7 Functional behaviour of VMSCB 

The functional behaviour of VMSCB when it handles an incoming call is described in 3GPP TS 23.018 [6]. The 
procedure specific to Support of Optimal Routeing is specified in this subclause. 

9.7.1 Procedure Handle_ORLCF_VMSC 

The procedure UUS_ICH_Handle_LCF is specific to UUS; it is specified in 3GPP TS 23.087 [9]. 
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Figure 12: Procedure Handle_ORLCF_VMSC 
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1 Contents of messages 



This clause specifies the changes to the content of each message shown in clauses 5, 6 and 9, including those messages 
which are already specified for UMTS but which require changes for Optimal Routeing. It should be read as a 'delta' on 
the corresponding clause of 3GPP TS 23.018 [6]; those information elements which are the same for SOR as for the 
basic call without OR are not specified in this clause. 

In the tables which follow, information elements are shown as mandatory (M) or conditional (C). A mandatory 
information element shall always be present. A conditional information element shall be present if certain conditions are 
fulfilled; if those conditions are not fulfilled it shall be absent. 

10.1 Messages on the B interface (MSC-VLR) 

10.1.1 Send Info For Outgoing Call 

This message is specified in 3GPP TS 23.018 [6]. 

1 0.1 .2 Send Info For Outgoing Call negative response 

This message is specified in 3GPP TS 23.018 [6]. 

1 0.1 .3 Send Info For Incoming Call 

This message is specified in 3GPP TS 23.018 [6]. 

10.1.4 Send Info For Incoming Call ack 

This message is specified in 3GPP TS 23.018 [6]. Thie following additional information elements are 

required: 



Information element name 


Required 


Description 


OR indicator 


C 


Indicates whether the call has been routed directly from a GMSC not in 
the same PLMN as the HLR. Shall be present if it was received in the 
Provide Roaming Number, otherwise shall be absent. 


GMSC address 


C 


E.164 address of the GMSC. Shall be present if it was received in the 
Provide Roaming Number, otherwise shall be absent. 


Call reference number 


C 


Call reference number used by the GMSC for this call. Shall be present if 
it was received in the Provide Roaming Number, otherwise shall be 
absent. 


OR not supported in GMSC 


C 


Indicates that the GMSC does not support Optimal Routeing. Shall be 
present if it was received in the Provide Roaming Number, otherwise shall 
be absent. 



10.1.5 Send Info For Incoming Call negative response 



This message is specified in 3GPP TS 23.018 [6]. 
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10.1.6 Complete Call 

This message is specified in 3GPP TS 23.018 [6]. The following additional information elements are 

required: 



Information element name 


Required 


Description 


OR indicator 


C 


Indicates whether the call has been routed directly from a GIVISC not in 
the same PLIVIN as the HLR. Shall be present if it was received in the 
Provide Roaming Number, otherwise shall be absent. 


GMSC address 


C 


E.164 address of the GMSC. Shall be present if it was received in the 
Provide Roaming Number, otherwise shall be absent. 



10.1.7 Process Call Waiting 

This message is specified in 3GPP TS 23.018 [6]. The following additional information elements are 

required: 



Information element name 


Required 


Description 


OR indicator 





Indicates whether the call has been routed directly from a GIVISC not in 
the same PLMN as the HLR. Shall be present if it was received in the 
Provide Roaming Number, otherwise shall be absent. 


GMSC address 





E.1 64 address of the GMSC. Shall be present if it was received in the 
Provide Roaming Number, otherwise shall be absent. 



1 0.2 Messages on the C interface (MSC-HLR) 
10.2.1 Send Routeing Info 

This message is specified in 3GPP TS 23.018 [6]. The following additional information elements are 

required: 



Information element name 


Required 


Description 


Interrogation type 


M 


Indicates the type of interrogation: basic(for routeing information for an 
MT call) or forwarding (when the GMSC has been asked to resume call 
handling for OR of late call forwarding). 


OR interrogation indicator 


C 


Indicates that the interrogation is from a GMSC not in the same PLMN as 
the HLR. Shall be present if the interrogation is from a GMSC not in the 
same PLMN as the HLR, otherwise shall be absent. 


OR capability 


C 


Indicates the phase of OR which the GMSC supports. Shall be present if 
the GMSC supports OR, othenwise shall be absent. 


GMSC or gsmSCF address 


M 


E.1 64 address of the GMSC. 


Call reference number 


C 


Call reference number used by the GMSC for this call. Shall be present if 
the interrogation type=basic call, otherwise shall be absent. 


Forwarding reason 


C 


Indicates the reason for forwarding (on busy, on no subscriber reply, or on 
mobile subscriber not reachable). Shall be present if the Interrogation 
type=forwarding, otherwise shall be absent. 


Basic service group 


C 


Basic service group which applies for this call. Shall be present if the 
Interrogation type=forwarding, otherwise shall be absent. 


Basic service group 2 


C 


Basic service group which applies for this call. Shall be present if the 
Interrogation type=forwarding and if the VMSC has determined that the 
forwarded call is to be treated as a SCUDIF call in accordance with the 
rules in 3GPP TS 23.172[10], otherwise shall be absent. 
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1 0.2.2 Send Routeing Info ack 

This message is specified in 3GPP TS 23.018 [6]. Two new information elements are required, and the 
condition for the presence of one existing information element is changed, as shown in the following 

table. 



Information element name 


Required 


Description 


Forwarding interrogation 
required 


C 


Indicates that the GIVISC shall interrogate the HLR for routeing 
information for late call forwarding. Shall be present if the SRI ack 
contains an MSRN and GIVISC has to interrogate the HLR for routeing 
information for late call forwarding, otherwise shall be absent. 


VIVISC address 


C 


E.164 address of the VMSG in whose area the B subscriber is currently 
registered. Shall be present in the Send Routeing Info ack if the OR 
interrogation indicator in the Send Routeing Info was present and the HLR 
supports optimal routeing of basic mobile-to-mobile calls and the HLR has 
not determined that the call is to be forwarded, otherwise shall be absent. 


Roaming number 


c 


E.1 64 address required to route the call to the VMSC of the B party. Shall 
be present in the Send Routeing Info ack which is sent in response to a 
Send Routeing Info with Interrogation type=basic if the HLR has 
determined that the charging requirements for optimal routeing are not 
contravened and that the call is not to be forwarded, otherwise shall be 
absent. 



10.2.3 Send Routeing Info negative response 

This message is specified in 3GPP TS 23.018 [6]. The negative response information element can take the following 
values in addition to those specified in 3GPP TS 23.018 [6]: 

OR not allowed. 

Busy subscriber. 

No subscriber reply. 

1 0.3 Messages on the D interface (VLR-HLR) 
10.3.1 Provide Roaming Number 

This message is specified in 3GPP TS 23.018 [6]. The following additional information elements are 

required: 



Information element name 


Required 


Description 


GMSC address 


C 


E.164 address of the GMSC. Shall be present if it was received by the 
HLR in the Send Routeing Info, otherwise shall be absent. 


Call reference number 


C 


Call reference number used by the GMSC for this call. Shall be 
present if it was received by the HLR in the Send Routeing Info, 
otherwise shall be absent. 


OR interrogation indicator 


C 


Indicates that the HLR received the corresponding Send Routeing Info 
from a GMSC not in the same PLMN as the HLR. Shall be present if 
the HLR received the Send Routeing Info from a GMSC not in the 
same PLMN as the HLR, otherwise shall be absent. 


OR not supported in GMSC 


C 


Indicates that the GMSC does not support OR, and that RCH shall not 
be sent. Shall be present if the HLR received the Send Routeing Info 
from the GMSC without the OR-capability information Element, 
otherwise shall be absent. 



10.3.2 Provide Roaming Number ack 

This message is specified in 3GPP TS 23.018 [6]. 
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10.3.3 Provide Roaming Number negative response 

This message is specified in 3GPP TS 23.018 [6]. 

10.3.4 Provide Subscriber Information 

This message is specified in 3GPP TS 23.018 [6]. 

1 0.3.5 Provide Subscriber Information ack 

This message is specified in 3GPP TS 23.018 [6]. 

1 0.4 Messages on the E interface (MSC-MSC) 
10.4.1 Resume Call Handling 

The following information elements are required: 



Information element name 


Required 


Description 


Call reference number 


M 


Call reference number used by the GMSC for this call. 


Forwarding reason 


M 


Indicates the reason for forwarding (on call deflection, on busy, on no 
subscriber reply, or on mobile subscriber not reachable). 


Basic service group 


M 


Basic service group which applies for this call. For SCUDIF calls, see 
3GPPTS 23.172 [10] for the use of this information element. 


IMSI 


M 


IMSI of the B subscriber. 


Forwarded-to number 


M 


E.I 64 number of the C subscriber. 


Notification to calling party 


M 


Indication of whether the calling party is to be notified that the call has 
been forwarded. 


Forwarded-to subaddress 


C 


Subaddress of the C subscriber (see 3GPP TS 23.003 [5]). Shall be 
present if a forwarded-to subaddress is stored in the VLR in association 
with the forwarded-to number; otherwise shall be absent. 


Redirecting presentation 


C 


Indication of whether the IVISISDN of the B subscriber shall be presented 
to the C subscriber. Shall be present if VMSCB supports the handling of 
the redirecting number, otherwise shall be absent. 


MSISDN 


C 


E.I 64 number which identifies the B subscriber. It will be used to create 
the redirecting number presented to the C subscriber. Shall be present if 
VIVISCB supports the handling of the redirecting number, otherwise shall 
be absent. 


CUG interlock 


C 


For the definition of this IE, see 3GPP TS 23.085 [8]. Shall be present if 
the VLR has determined that the forwarded call is to be treated as a CUG 
call in accordance with the rules in 3GPP TS 23.085 [8], otherwise shall 
be absent. 


CUG outgoing access 


C 


For the definition of this IE, see 3GPP TS 23.085 [8]. Shall be present if 
the VLR has determined that the forwarded call is to be treated as a CUG 
call with outgoing access in accordance with the rules in 3GPP 
TS 23.085 [8], otherwise shall be absent. 


Basic service group 2 


C 


For the definition of this IE, see 3GPP TS 23.172 [10]. Shall be present if 
the VMSC has determined that the forwarded call is to be treated as a 
SCUDIF call in accordance with the rules in 3GPP TS 23.172(10], 
otherwise shall be absent. 



10.4.2 Resume Call Handling ack 

This message contains no information elements. 

10.4.3 Resume Call Handling negative response 

The negative response information element can take the following values: 
OR not allowed. 
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Forwarding failed. 



£75/ 



3GPP TS 23.079 version 5.5.0 Release 5 41 ETSI TS 1 23 079 V5.5.0 (2004-06) 

Annex A (informative): 
Handling of an lAIVI at an IVISC 

An MSC which receives an I AM from an originating exchange may react in three different ways: 

It acts as a transit exchange, i.e. it relays the lAM to a destination exchange determined by analysis of the called 
party address, and thereafter relays other ISUP signalling between the originating and destination exchange until 
the connection is released. This behaviour is not specific to UMTS or GSM. 

It acts as a terminating exchange, i.e. it attempts to connect the call to an MS currently registered in the service 
area of the MSC. 

It acts as a GMSC, i.e. it interrogates an HLR for information to route the call. If the HLR returns routeing 
information, the MSC uses the routeing information from the HLR to construct an I AM, which it sends to a 
destination exchange determined by analysis of the routeing information from the HLR. 

The method which the MSC uses to determine how to handle the lAM is described in 3GPP TS 23.018 [6]. However, 
the number analysis required to derive the address of an HLR in a different PLMN from the MSC is much more 
extensive than that required to derive the address of an HLR in the same PLMN as the MSC - the MSC needs to be able 
to recognise the combination of country code and national destination code for every subscriber of every PLMN to 
which calls are to be optimally routed. In order to avoid the need to maintain the tables required to support this 
extensive number analysis, and the run-time processing load of performing the number analysis, optimal routeing of 
mobile-to-mobile calls is handled as a mobile originating CAMEL service; the gsmSCF analyses the destination address 
(after possible modification of the number by other MO CAMEL services) to determine whether the call is eligible for 
optimal routeing. If the call is eligible for optimal routeing, the gsmSCF indicates this to VMSCA, which routes the call 
to an associated GMSC function, which in turn sends a request for routeing information to the appropriate HLR. 

When a GMSC has interrogated an HLR and received an MSRN, the GMSC may need to route the call to the HPLMN 
of the called subscriber. If the call is routed through an MSC which has the capability to analyse an address to derive an 
HLR address, a method must be provided to prevent the transit MSC from performing a further interrogation of the 
HLR, using the MSRN as an MSISDN. The method used to prevent this further interrogation is a matter for the PLMN 
operator. 
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